One common usage of the Internet is multiplayer gaming. The first generation of large scale multiplayer Internet games included MUDs (Multi-User Dungeons) and their successors: MUSHs (Multi-User Shared Hallucinations) and MOOs (MUD Object Oriented). Unlike today's multiplayer games, these first generation games were all text-based adventure simulations whose form was derived from the old single player Infocom text-adventures (e.g., ZORK).
This first generation of multiplayer games were typically implemented using state machines, where each state corresponded to an environment description (e.g., “You are in a long narrow corridor with doors at both ends.”). Further, the player actions moved the players from one state to the next. In some implementations, objects used within a state were attached to that state, such that they were listed as part of the state description and may be obtained whenever a player returns to that state.
MUDs and their successors formalized the concept of a state by introducing the notion of a “room.” Specifically, each of the descriptive states corresponded to a room. Further, the rooms were implemented such that a player in a particular room may only interact with that particular room (e.g., the environment of the room) and players currently in the room. In addition, system performance with a given room (e.g., latency experienced by users in the room, etc.) was maintained by limiting the number of players who could simultaneously occupy a particular room.
With respect to the implementation, MUDs typically executed in a single memory space and usually as a single process. Further, the MUDs typically maintained all the active game states in memory and performed periodic dumps to a hard-drive back-up for failure recovery purposes. Today's multiplayer games that are based on event driven simulations currently have been built upon the foundations laid by the MUDs and their successors. In particular, the notion of a “room” still persists today. However, the “rooms” have evolved to represent a 3D space and are displayed to a user using 3D graphics. The evolved representation of “rooms” is now more commonly referred to as “regions” or “areas.” However, the underlying purpose of the room, i.e., to divide up to the user-base to handle scaling, has not changed.
Similar to its predecessors, each region (or more specifically the description of the state of the region) is still maintained in memory. However, the implementation of the regions has been modified to allow each region to execute in its own process in a separate memory space. The following description provides a brief overview of the operation of a multiplayer game that uses event driven simulation. Initially, a user logs into the multiplayer game via a login server. Once authenticated, the client (i.e., the computer through which the user is interacting with the multiplayer game) is instructed to disconnect from the login server and connect to a region server supporting (i.e., executing) the starting region, if the user is a new player. Alternatively, if the user is a returning player, the client is instructed to connect to the region server supporting the last region the player was in. Once the client is connected to the appropriate region server, the user may then participate in the multiplayer game. When the user moves to a different region, the corresponding client is instructed to drop the connection with the current region server and connect to the region server which supports the region to which the user has moved.
Similar to the implementation of rooms within the MUDs, the aforementioned regions typically limit the number of users that may be simultaneously connected to a region (or, more specifically, a region server supporting the region). When this limit is reached, the region is “full” and no additional users are allowed to connect until a user currently in the region disconnects from the region (i.e., leaves the region). However, to increase the number of users that may be allowed enter a particular region, multiplayer games may implement “shards.”
In general, shards correspond to simultaneously executing copies of a region within the multiplayer game. Depending on the implementation, each shard for a particular region may be executing on a different server. Thus, when a user attempts to move to a particular region, the multiplayer game attempts to connect the user to one of the shards that supports the particular region. While shards increase the number of users that may be in a particular region, the shards typically do not allow users within different shards of the same region to interact.